Network issues


Most versions of CU-SeeMe are usable on a home network without difficulty. Hubs, Switches, Routers, Firewalls, Proxy Gateways or Internet connection sharing devices have caused many problems. Some of the newer cable systems, DSL, ADSL and Satellite connections also prevent CU-SeeMe from working correctly. "Your IP address is incorrect, restart CU-SeeMe" is not really a Network problem but more of an operating system problem. This is the result of multiple network interfaces in your computer. On this site there is a whole page of help for those experiencing this error "Your IP address is incorrect, restart CU-SeeMe" Also the "Unable to connect to..." error can be a bit tricky as it's cause can be the internet itself, your ISP or the precise way of connection your computer has to the internet. A PING test (below) might help find out what is happening.

Many of the more expensive routers/switches (intelligent) have a DMZ feature that allows one PC to be on the internet with an ISP supplied IP (preferred fix).

Your goal is to get an Internet routable IP on the PC using CU-SeeMe.

A 192.168.x.x IP will only work with White Pine 4.0.2 (or above) MPCS reflectors only!!!

A good test of home network CU-SeeMe worthiness can be found at the web site. Click on the Test Your Firewall link and follow the directions. If this test fails it offers terse and limited help in fixing the issue, please come back here.

A good clean simple approach

Re: Linksys, Mac, and Cornell CU

Posted By: Joe

In Response To: Re: Linksys, Mac, and Cornell CU (Wally)

I emailed Linksys a couple of months ago about this problem and they sent me back a detailed (form email) that supposedly would fix this wrong IP problem which trying to connect to Cuseeme. I tried it all.....and never got it to work.

I did manage to over come this problem by switching my IP settings (PC machines) from a specified IP number to obtain automatically. Then I shut down my computer. Take the DSL line from the back of the router and connecting it directly to my computer network card. Doing this....I can get all cuseeme reflectors.

It sounds complicated...but it isn't really and after you have danced naked on Cuseeme, you can switch the line and the settings and go back to your normal business. This is the only method I've found to get past this firewall problem. Remember to write down your specified IP numbers and subnet numbers so you can fill them in when you change back your settings. I have also found that I can get into the Cu-Central sites without all this switching around.....wish this problem could be solved without all this switching.....good luck. Joe

Note: This fix, if you have a home network, leaves the other users on it with no connection to the internet while you are 'dancing naked on cuseeme' (using CU-SeeMe).

Hello, is there anyone out there?

Read thru several pages before giving up as you may have multiple problems and not know it! By this I mean you might have invalid reflectors or IP addresses in your listings. Many times they change and don't update their websites. Also, as time has gone on less reflectors are out there. A few years ago there were over 200. Just recently it has dropped below 100. The Ping and traceroute tests will help sort this out as well as tell you if the ISP the reflector is on is even on the net! Some disconnects like this are temporary but in light of the recent Dot Com failures some are permanent! What I will try to illustrate here to CU-SeeMe users is a 'big picture' to 'little TCP/CU-SeeMe bits' method of finding the problem.

Starting with the most common and the 'big picture' one:

Is the host name or IP in your reflector dialing list correct? Many times the reflector has moved and the user is unaware. The reflector MOTD aka Message Of The Day (that annoying box one has to click to join the room) may not have announced it OR the reflector's website had not mentioned it (or there isn't a website). Some reflector operate their member lists on e-mail or ICQ and folks that got left out in error or were leaked the info get left in the lurch. Some public reflectors do go private and leave a lot of folks unknowing only taking the best of the regulars with them. This has happened a lot in the past when a reflector gets popular. A distant possibility is you did something wrong (or pissed someone off) and got left out on purpose! See the Links page for my recommended reflector listings.

Can you use Trace Route tools to reach the reflector's computer? Many times the internet breaks (damn backhoe operators cut another fiber!) to the point that a part of the internet (ISP) is no longer reachable. Trace Route shows progress to a point and then stop short of reaching the reflector IP. Some ISP's have a second route circuited but it takes time to take over and allow internet connections to resume. These problems typically last a few 10's of minutes to several hours (days away from big cities or in a local disaster) depending how far out on the internet (not in a big city?) the ISP was! Try try again is the only hope :) More on Trace Route below.

Ping shows some failure (1 or 2 out of 4 attempts) but not all. This could be a congested (slow DSL/Cable connection) or failing network connection. Reflectors need upwards of 1,000 kbps (a T1 line is close to this but lately DSL/Cable isn't) to be regarded as fast. Sometimes this ping failing indicates the computer the reflector is on is very overworked. Total failure of ping when trace route works may be by design as ping responses can be turned off independent of trace route responses (somewhat rare). More on Ping below.

Ping and trace Route are fine but no connect. Well, 5 things come to mind right away.

  1. The reflector was taken down.
  2. The reflector failed to restart after a reboot. This is how it was installed on the server.
  3. The reflector was moved. See the sub-section 'Is the host name or IP in your reflector dialing list correct' above. A few good souls leave the old reflector up after the move with a conference limit of one participant. They then place into the MOTD the new IP and CID information for those that do connect.
  4. The reflector information may be a name and not an IP. Example: This name to IP conversion can slow the connect. Try the fix in item below that follows. This may be related to a DNS timeout or lookup failure. Using the IP in this situation might seem like a good workaround at first but this reflector is using as it's domain. That's one of mant Dynamic DNS services. It allows the name to stay constant and the reflector's IP to change. If the IP changs the workaround fails.
  5. A rare case is multiple firewalls slowing connects to beyond CU-SeeMe's timeout. Try connecting and then disconnect after 20 seconds or so. Then try again. It might connect.

This point is still 'under construction' so to speak, stay tuned :)

Can't connect with Cornell but you can with White Pine. The reflector may have a configuration stopping that. One cause is a missing reflect.conf file (at the reflector) and the other is a reflector operator that has deemed Cornell inappropriate. They have prevented connections made with it explicitly in the reflector's setup. the only cure is to contact them (to enlighten or appeal) or use White Pine for that (those) reflector(s).

Only certain reflectors give me moving videos, why? This one most times is related to the combination of reflector type and/or the ISP. a) The newer White Pine 3.5.x, 4.x and 5.x MPCS reflectors have some enhancements that give them the ability to make more videos have motion content on a given connection speed. b) A really bad ISP/connection to the internet can also make this happen. Disconnect and redialing may help if it's just a bad connection. I know of several users stuck in a 'one ISP location' that are affected by this efect and always get a lousey connection speed and packet loss.

PING test

The remote computer (reflector or called party) HAS to be visible with PING to the computer running the CU-SeeMe client software. PING is an command ling network testing tool use to verify that a remote computer is functioning. Get to ping from Start, Run and then type command followed by clicking OK. Type the word ping, a space and then the IP address (or hostname) your trying to verify. Ping verifies a connection to a remote host by sending an ICMP (Internet Control Message Protocol) ECHO packet to the host and listening for an ECHO REPLY packet. Here is the result of a ping to one of the White Pine corporate reflectors.

Ping - Address:

	#1 ( Echo Reply, ttl=240, 170 ms
	#2 ( Echo Reply, ttl=240, 160 ms
	#3 ( Echo Reply, ttl=240, 151 ms

The key part of this is the "Reply" in the ping output. That's the result of a successful test above. If you get Request timed out it may mean that the remote computer is down or unreachable. What can break this? Hubs, Firewalls, Switches, Proxy Gateways, PC internal routing and the internet itself are the main causes. This Internet related cause typically happens when you can connect to most reflectors but not one or a few others (or the reflector is down/gone). The internet connection of one ISP to the Internet can get messed up, causing a "Unable To Connect To ..." failure. For this cause you just have to wait for them to fix the problem. Unless this problem is on your home network.

Trace Route

How does one know where? Well, there is another command called formally Trace Route that can help. It's DOS command is tracert. If all of the hops fail, it's likely the cause is on the local network and not on the internet. Below is a good tracert output showing the reflector is at also known as First Virtual Corporation which is White Pine's new name.

good one!

Here is a Trace Route that failed. Note hops 14 and 15, they are * in the DOS version instead of No Response.

Bad one
TraceRoute - Address:

#1 Unavailable ( TTL Exceeded, ttl=255, 170 ms
#2 Unavailable ( TTL Exceeded, ttl=254, 130 ms
#3 ( TTL Exceeded, ttl=253, 120 ms
#4 ( TTL Exceeded, ttl=252, 130 ms
#5 ( TTL Exceeded, ttl=251, 120 ms
#6 ( TTL Exceeded, ttl=250, 170 ms
#7 ( TTL Exceeded, ttl=249, 130 ms
#8 ( TTL Exceeded, ttl=248, 131 ms
#9 ( TTL Exceeded, ttl=246, 130 ms
#10 ( TTL Exceeded, ttl=245, 141 ms
#11 ( TTL Exceeded, ttl=245, 130 ms
#12 ( TTL Exceeded, ttl=244, 140 ms
#13 Unavailable ( TTL Exceeded, ttl=243, 140 ms
#14 No response (): , ttl=,  ms
#15 No response (): , ttl=,  ms


Firewalls can be a device or process that enforces an access control policy between two points on a network. The actual means by which this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one which exists to block traffic, and the other which exists to permit traffic. CU-SeeMe has some unique network requirements that, when a firewall is present can prevent connection inbound, outbound or both. The Wingate, McAfee, Symantec (Norton), Sygate and Internet Connection Sharing aka ICS (included with all versions of Microsoft Windows from the release of Windows 98 Second Edition onward) are all types of firewalls. With these types of firewalls CU-SeeMe will only work on the PC with the internet connection. Firewall product features lists many times may not disclose the inclusion of the NAT aka Network Address Translation feature. Firewalls are now found in hubs, routers, switches and in internet Suite software from several vendors (Wingate, McAfee, Norton - Symantec). Personal firewalls like Zone Alarm and Tiny Personal Firewall are CU-SeeMe friendly, with slight (ZA) to moderate (Tiny) configuration needed to get them working with CU-SeeMe.


Most versions of CU-SeeMe requires a connection with the NAT aka Network Address Translation feature disabled to work successfully. On many network devices (hubs, routers and hardware based firewalls) if a firewall is present many ports may be blocked by default; for example, they may block all ports except WWW, FTP, POP3, SMTP, NTTP, IRC and SNMP traffic. You must then open or forward the ports shown below to allow CU-SeeMe to work. These ports must also be opened bi-directionally. The ports that need to be opened are:



PORT Number


7648, 7649


1503 (T.120)


7648, 7649




56800 (CU5)
* = mandatory, others optional

It's important to note that port forwarding under NAT will many times only partially work with White Pine MPCS version 4.0.2 and above reflectors. Port forwarding/opening is of no help for earlier reflector versions, which amounts to the other 98% of the reflectors on the net!!!

Network Address Translation, when combined with port forwarding on a firewall has been reported to make chat disappear. The chat of anyone behind the NAT device invisible to all others UNLESS Reflector CID 0 is the one used. If all user connect on CID 0 the chat will come through. This is due to a bug in the CU-SeeMe protocol and there is no setting either on the desktop or reflector to fix it at the present time.

Many network devices, if they are located between the PC with CU-SeeMe on it and the internet will require these ports to be unblocked to allow CU-SeeMe to work. A PC located in the DMZ on a router will typically have all ports open by default and will not require this.

Why is Network Address Translation so bad?

The CU-SeeMe data sent to the reflector has within the IP packet the IP address of the PC with the sending client. So, two IP's are sent. NAT obscures one of those IP's and creates a situation that causes the "Your IP address is incorrect, restart CU-SeeMe" error. How can you tell if your PC is on a NAT provided IP? The easiest way is to look at your IP address. If it has 10.xx.xx.xx or 192.168.x.x (where xx could be any number from 0-254) you are on NAT. The other way people have discovered if NAT is present is when they connect to a reflector they see "all eyes open ", this is indicative of a NAT connection. Others have reported chat not making it through and an inability to connect to conferences other than 0 CID. Having a NAT IP limits you to only accessing those reflectors that use White Pine Reflector Software MPCS 4.0.2 (and above). Try connecting to one of the Whitepine reflectors aka web site. Check their web site for updates. If you can then its the NAT IP problem. If you cannot disable NAT, you must replace the device with one that lacks NAT or allows it to be disabled.

Network Address Translation, when combined with port forwarding on a firewall has been reported to make chat disappear. The chat of anyone behind the NAT device invisible to all others UNLESS Reflector CID 0 is the one used. If all user connect on CID 0 the chat will come through. This is due to a bug in the CU-SeeMe protocol and there is no setting either on the desktop or reflector to fix it at the present time.

Why is DHCP behind a router so bad?

Like NAT it bypasses your ISP's assigned IP address by supplying a different one. Wrong IP error again! If you cannot disable it, you must replace the device with one that lacks DHCP or allows it to be disabled.


The newest models from D-Link, Linksys, NetGear and others are now coming standard with features (firewalls, DHCP and NAT) usually found on the more expensive Routers or Switches offered in earlier that 1st Quarter 2001. These CU-SeeMe breaking features are sometimes disguised as Privacy, KidGuard or Protection options (read market speak here). Those features are good for most of these users. It isn't so good for CU-SeeMe as these features cannot be turned off individually or at all. This may sound counter intuitive but actually utilizing the cheaper (aka dumb) hub in place of an intelligent switch or router helps many times. When a number of people are sharing a high speed connection a hub isn't the best solution, use a switch instead.

Once these ports are opened the PC running CU-SeeMe can dial out to individuals and connect to the newest versions of Meeting Point reflectors without difficulty. To utilize the other 95% of the reflectors on the Internet however one must open the ports above and disable NAT. Many of the more expensive routers/switches (intelligent) have a DMZ feature that allows one PC to be on the internet with an ISP supplied IP (not from the router/switch's internal DHCP service). You may have to change to a different router/switch brand and/or model that has a DMZ feature if your ISP connection dictates that a hub not be used. This may sound counter intuitive but actually utilizing the cheaper (aka dumb) hub/switch in place of an intelligent switch (with firewall) or router (with firewall) achieves this many times. My Linksys EZXS55W EtherFast 10/100 5-Port Switch is less than $50 USD and has no CU-SeeMe blocking features. A few have reported that using the DMZ host setting in the linksys and others allows one PC to work properly. Not all have a DMZ feature.

Cable, DSL and ADSL

The DSL/Cable software provided to you by your ISP sometimes causes problems with CU-SeeMe. The software they use (Usually found in your network settings as NTSPPPoE), and the fact that they have you set up where the modem and the network card have set IP's, when you're getting a dynamic IP each time you log on. To solve this, delete all the network settings dealing with NTSPPPOE, and install RASPPPoe instead. RASPPPoe is a free program, and works with for Windows 98/98SE/ME/2000/XP/2002. It is available at

Internet Connection Sharing aka Proxy Gateways

The Wingate, Sygate, MS Proxy Server, JSentry, Com Socks, WINProxy and the Microsoft Windows Internet Connection Sharing are all types of Proxy Gateways. A Proxy Gateway is like a middle-man, relaying messages from internal clients to external services. The proxy gateway frequently use NAT, also known as Network Address Translation. There are no work arounds for this feature in most of them.

CU-SeeMe and Linux IP-Masquerade

IP Masquerading can be turned off and allow CU-SeeMe to work client to client only. People running IP-Masquerade on Linux will find a number of tips here:

If you need more explicit information on configuring CuSeeme and Linux IP-Masquerade, see Michael Owings's CuSeeMe page for a Mini-HOWTO or The IP Masquerade Resources for a mirror of the Mini-HOWTO.

Back to Hoople's Home Page

Comments? Send them to click to e-mailHoople <>

All contents © 1997-2002 by Hoople

Last updated Tuesday, April 16, 2002 3:01:44 PM